The smail mail system is similar to the sendmail system in most of its actions,
although the configuration process is different. In some ways, smail is easier to work
with than sendmail, and it can be a good choice for smaller systems. If you choose to use
smail as your mailer, you will have to make some manual modifications to configuration
files because there are few automated or scripted routines available.
The smail system has many options and configuration details, most of which are never
used. This chapter looks at the primary controlling parameters that most Linux users may
need and essentially ignores those that are very seldom (if ever) used in real situations.
For more information on the options and configuration controls not covered in this
chapter, see the man pages or smail documentation. Essentially, this chapter shows you how
to get smail up and running quickly to handle the situations most Linux systems will find
themselves working with.
The smail system is governed by a daemon that is usually started when the system enters
multiuser run mode. From then on, smail watches for incoming connections (TCP or UUCP,
usually), and it processes any incoming mail when it is received. Because smail runs as a
daemon, this allows fast processing and delivery of incoming mail without having to
physically start a mail program at intervals. When mail is received through a UUCP
connection, the rmail program is often called to handle the delivery of the mail.
The smail system was designed to process incoming mail immediately, routing it to the
receiver. You can override this in the main configuration file, usually called
/usr/lib/smail/config, which may be necessary in high-traffic situations or when a machine
is heavily loaded. When desired, the inetd daemon can handle incoming mail traffic and
spawn smail to handle the delivery at specific intervals. However, using smail as a daemon
generally involves less overhead and system resources than spawning it every time mail has
to be handled, so the daemon approach is recommended.
The smail system handles outgoing mail through the use of a connection to a user's
mailer. For example, if you send a message from one of the Linux mailer agents such as Elm
or mail, that application sends the mail and recipient names to the rmail (usually
/usr/bin/rmail) program for delivery. Some mail agents send outgoing mail to the sendmail
program instead of rmail, which also has to be accounted for. As you will see in the next
section, both incoming and outgoing mail is usually handled by creating links between
smail, rmail, and sendmail.
The smail mail-handling routine is broken into three distinct and separate parts: the
router, the director, and the transport. The router handles address resolution and the way
in which messages are sent between machines. The director handles forwarding and aliases
that may be used in messages. The transport handles the actual transfer of messages. Each
of the three components can be configured separately within smail using separate files
called routers, directors, and transports (which usually reside in the /usr/lib/smail
directory with the smail configuration files). You will look at modifying the default
behavior of each component later in this chapter.
Most Linux systems have the smail program reside in the directory /usr/local/bin,
although a few other locations are popular as well. You need to know the exact directory
path to smail in order to properly configure the system, so find the executable. You can
locate its path with the following command:
find / -name smail -print
The smail system requires several links to exist so smail can execute properly. The two
most important links are to the files /usr/bin/rmail and /usr/lib/sendmail (sometimes
located as /usr/sbin/sendmail, depending on the version of Linux). These links are
necessary because most user mail applications send outgoing mail to either rmail or
sendmail (depending on the mail software), and this has to be redirected to smail. Links
allow this redirection to occur transparently without altering the user mail applications.
Verify that the rmail and sendmail files are linked to smail, and if not, establish the
links. Usually, the links established are symbolic, and they will show in a directory
listing with an entry like this:
lrwxrwxrwx 1 root root 6 Sep 16:35 file1 -> file2
The arrow (->) shows that a symbolic link exists. (For more information on links and
symbolic links, see Chapter 18, "Filesystems and
Disks.") Check both the rmail and sendmail binaries for these symbolic links. If the
symbolic links do not exist already, create them with the following commands:
ln -s /usr/local/bin/smail /usr/bin/rmail ln -s /usr/local/bin/smail /usr/lib/sendmail
Of course, you should substitute whatever directory pathnames are valid on your system
for smail, sendmail, and rmail. Once you have created the links, verify that they exist by
displaying the directories and look for the symbolic link notation shown earlier.
If mail may enter or leave your system through an SMTP channel, you should also
establish a link between the smail program and the smtp system. Use the following command
to set up the link (substituting proper paths for your system):
ln -s /usr/local/bin/smail /usr/sbin/smtpd
Next, the SMTP service has to be enabled through the TCP configuration files. You do
this by setting the /etc/services file to specifically enable SMTP connections. There is a
line in the /etc/services file that looks like this:
smtp 25/tcp # Simple Mail Transfer Protocol
Verify that this line is not commented out (has a pound sign as the first character).
This line allows the SMTP link to be established as TCP port number 25 (the default
value).
If you are going to leave smail as a daemon (started automatically with the system
boot), ensure that the smail daemon is started in the rc files (such as rc.inet2). The
usual command line for the smail daemon looks like this:
/usr/local/bin/smail -bd -q15m
The -bd option turns the daemon operation of smail on, and the -q15m tells smail to
process messages every 15 minutes. If you want more frequent mail delivery, change the
value in the rc file. Alternatively, if you want mail processing less often to relieve a
heavily loaded system, increase the value.
If you decide not to run smail as a daemon and want it spawned by inetd whenever mail
arrives, comment out the daemon lines in the rc files (usually rc.inet2). You cannot run
smail in both daemon and spawned mode. Next, modify the /etc/inetd.conf file to contain an
entry like the following:
smtp stream tcp nowait root /usr/sbin/smtpd smtpd
You must have the symbolic link between smtpd and the smail program for this command to
function properly.
The configuration file changes necessary for smail depend on which connection system
you use for obtaining mail. In other words, the configurations change if you are using
UUCP (which is the easiest to set up) or a TCP connection on a network. This chapter looks
at each of the configuration processes separately. You can follow both discussions, if you
enable mail through both methods.
Configuring the smail system for use with UUCP incoming and outgoing mail messages is
very simple. You need to edit the default smail configuration file, usually stored as
/usr/lib/smail/config. Some versions of smail include a sample configuration file as
config.sample in the same directory. You can use either as a template for the UUCP
modifications.
Use any ASCII editor to edit /usr/lib/smail/config. You need to make four changes. The
changes are for these variables:
| visible_domain | The domain names your site belongs to |
| visible_name | Your site's full domain name |
| uucp_name | Your site's UUCP-based name (usually the same as visible_name) |
| smart_host | The name of the UUCP host |
Each parameter in the /usr/lib/smail/config file uses the same format of
variable=value. There should be no spaces on either side of the equal sign on any line. A
pound sign precedes comments in the file.
Begin by setting the domain name of the local machines. Locate the line in the
/usr/lib/smail/config file that defines the variable visible_domain, which will usually
look similar to this:
# Our domain name visible_domain=tpci
The visible_domain variable sets the domain names your site belongs to, and it will
usually be the fully qualified domain name and any aliases that may be in effect. This
field is used by smail to find out if the recipient of a message is local or not. The
smail system takes the message and extracts the recipient's address, comparing it against
the local machine name (from the hostname command) and all values specified on the
visible_domain variable. If there is a match to any of these names, the message is for a
local recipient. If no match occurs, the message is routed externally.
If there is more than one valid value for a local domain name, the values are separated
by colons, as shown in this example:
visible_domain=tpci:tpci.com:tpci.UUCP
If your site is properly registered on UUCP maps, add the domain uucp to the list of
valid values, as well. In this example, you belong to the domain tpci (from the full
domain name tpci.com), and uucp:
visible_domain=tpci:tpci.com:uucp
When a message is to be routed out of the local machine, the smail system appends the
local machine's full domain name as part of the routing information. The full local
machine name is defined in the /usr/lib/smail/config line that deals with the
visible_domain variable. The line looks something like this:
# Our domain name for outgoing mail visible_name=tpci.com
As a general rule, the visible_domain value must be a combination of the hostname and
one of the domains given in the visible_domains variable. Otherwise, the smail system may
bounce incoming mail issued as a reply to mail sent from your site as being
unrecognizable.
The visible_name value is usually your fully qualified domain name (if you have one) or
a domain name that exists in other routing tables.
The /usr/lib/smail/config file sometimes contains an entry for a variable called
uucp_name. This variable is usually optional, as long as the variables visible_domain and
visible_name are properly filled in. The uucp_name variable is used when the name of the
system returned by the hostname command is not the name that is registered with the UUCP
mapping tables. For example, your UUCP mapping name may be darkstar, but you may have
changed your machine's name to vader for any number of reasons. You can use the uucp_name
variable to correct this change, without requiring updates to the UUCP mapping tables.
To set a value for the uucp_name variable, look for (or create, if one doesn't exist)
the lines that define the variable. Usually, the lines look like this:
# UUCP mapping name uucp_name=tpci.com
If your name is properly registered as set in the visible_name variable, you can simply
repeat the value in the uucp_name variable with no ill effects. If your site name has
changed, enter the proper value instead.
Some systems use another machine as a smart host that handles the routing of messages
to and from other networks. If you are using a smart host, you should put its name in the
/usr/lib/smail/config file next to the variable smart_host. Look for entries in the file
that resemble these lines:
# Smart host smart_host=merlin
In this case, any mail for other networks is forwarded by smail to the machine merlin
(in the fully resolved domain name merlin.tpci.com, based on the smart_host and
visible_name variables). That machine can then take care of the routing out of the
network. Any machine name given in the smart_host field must be reachable by UUCP, which
means having a corresponding UUCP configuration entry. (See Chapter 27,
"UUCP," for more information.)
If you are going to use a network connection to transfer mail, you need to make
modifications to the /usr/lib/smail/config file that specify the types of connections and
host names. There are several different methods of configuring mail systems for a network.
These methods include using NFS (Network File System) to allow a single configuration file
shared by all machines, using POP (Post Office Protocol) or IMAP (Interactive Mail Access
Protocol) to handle mail on a central site, and setting up each machine as an independent
mail handler. The configuration process for all these methods is much the same. The
difference is whether the configuration files reside on each machine in the network, or on
a single machine that is then accessed by NFS or SMTP by other machines.
Start the configuration process by establishing the local domain names using the
variables visible_domain and visible_name. These variables were discussed in detail in the
section on configuring smail for UUCP., so the explanation will be limited to showing
final examples of these two variables. An example of these variable definitions looks like
this:
# Our domain name visible_domain=tpci.com # Our domain name for outgoing mail visible_name=tpci.com
This code sets the local domain name and domain resolution names. The entry for
visible_domain is used by smail to attach to all outgoing mail packages (instead of
whatever name is generated by the hostname command). Both visible_domain and visible_name
are often the same.
The next configuration step is to set the name of a smart host that handles
out-of-network messages. If you are not using a smart host, or your machine handles the
network connections itself, you won't need to enter these values. The variables involved
in setting up a smart host are smart_path and smart_transport. The smart_path sets the
machine name of the smart host (which must be resolvable with the domain name given in
visible_domain). The smart_transport variable specifies the type of protocol to be used to
connect to the smart host. Because most smart hosts communicate (for mail purposes, at
least), with SMTP, that is the most often used value, as shown in this extract from a
/usr/lib/smail/config file:
# smart host routing # smart host name smart_host=merlin # communications protocol to smart host smart_transport=smtp
The smart_transport value of smtp (lowercase letters only) is used to identify the SMTP
connection protocol.
As mentioned at the start of this chapter, smail can use many configuration options and
command line options, although most are of little interest to most Linux system users. A
few of the options may be of interest if you want to modify the basic behavior of smail.
This section examines these options.
Both UUCP and TCP-based smail systems can add an entry to the /usr/lib/smail/config
file that prevents misrouted mail from bouncing around the network until it dies from
excess hops. This is controlled by the auth_domains variable, which is used by smail to
validate any incoming mail package. When smail receives a message for the local network
machine, it checks to see whether the local machine's name is known. If not, the message
is returned to the sender.
To set an authoritative name validation in the /usr/lib/smail/config file, check for
(or add) these lines:
# auth domain name auth_domains=tpci.com
This code limits the mail messages bouncing around the local network to any valid host
name in the domain tpci.com. If the name is not recognized in the local network, it
doesn't get circulated. This sometimes can help prevent congestion on a network when large
files are misrouted.
You can set the smail system to process incoming mail in different ways (other than the
daemon or spawned process startup options discussed earlier). You can set smail to store
incoming and outgoing messages in a queue and process them at later times, or to process
mail immediately. This process is controlled with the queue_only and delivery_mode
variables.
The queue_only variable is a Boolean value that, if set, enables the delivery_mode
variable, which can be set to one of three values:
| foreground | Processes incoming messages immediately |
| background | The message is delivered by a child process |
| queued | Holds the message for later processing |
When queuing is enabled, messages are held in a smail queue (usually in
/var/spool/smail/messages) until the queue is processed. The processing is controlled by
the -q option on the smail command line (if smail is started as a daemon), or by issuing
the command runq from a crontab file (if smail is run from inetd). (For the latter to work
properly, runq must be linked to smail).
Recall the startup command line from the rc file shown earlier:
/usr/local/bin/smail -bd -q15m
You remember that the queue is processed every 15 minutes in this example. The queue
process command can be set to any value, but it should not be left for too long as the
queue files can get very large.
You can display the current contents of the smail queue by issuing the smail command
with the -bp option or with the command mailq, which should be linked to smail.
Every network should have a postmaster, which is a user who receives all the status
messages from the mail systems as well as queries from other networks about the local area
network and its users. By default, the postmaster ID is set to root, although you can
override it with the command like this in the /usr/lib/smail/config file:
postmaster=tparker
This command routes all messages for the postmaster to the user tparker. You only need
to specify this option in the /usr/lib/smail/config file if you want to change the default
setting of root.
You can configure the postmaster to receive all error messages that are generated
because of configuration errors. Add the Boolean variable to the /usr/lib/smail/config
file:
+error_copy_postmaster
If this entry doesn't exist with a plus sign ahead of it, messages are not copied to
the postmaster.
In normal operation, smail uses two log files to record actions. Most transactions are
recorded in the file /var/spool/smail/log/logfile (your path may differ, depending on the
version of Linux). Each entry in the log reflects a complete smail transaction and
includes the identification number of the message, sender, recipient, times, size, and
routing information. You can use the contents of the log file to check for proper behavior
of the smail system.
Errors and other problems are recorded in the file paniclog (usually
/var/spool/smail/log/paniclog). An entry in this file tends to show the basic information
about a message as well as the reason the message couldn't be sent. For example, the most
common error is a failure to route a message through SMTP, which produces the log summary:
(ERR_148) transport smtp: connect: Connection refused
If you see these error messages in the paniclog file, it usually means SMTP has failed,
the connection is not responding because the remote host is down, or the TCP service is
not enabled (check /etc/services).
If the entries in the paniclog file don't help you isolate a problem, you can enable a
debugging mode on smail by adding the option -d followed by a number to the startup
command. The number reflects the amount of debugging information to be generated and
displayed on the screen. It is best to kill the smail daemon (if one is being used) and
restart it at a shell prompt with this option active, instead of embedding the debug
option in the rc file.
If you are not getting any mail forwarded to your mailbox, check the pathnames of the
mailbox files. Usually, mailboxes are stored in /usr/spool/mail/username where username is
each user's mailbox. Some versions of Linux use /var/spool/mail instead, and some mail
applications may be expecting a specific address for the mailbox. If you are not sure
whether the mailbox location is correct, try creating links between
/usr/spool/mail/username and /var/spool/mail/username.
The configuration files and processes mentioned earlier apply for most Linux systems,
and many systems will require no further actions than those already covered. However, as
mentioned earlier in this chapter, smail's three components (router, director, and
transport) can each be further configured to modify their behavior. This capabilty can
help you fine-tune or modify your smail installation to meet particular network needs. The
only component you really need to examine in detail is the router, as the director and
transport seldom need customization for a typical Linux installation.
In most cases, the behavior of each smail component is handled by a file (or several
files) based in the smail configuration directory (usually /usr/lib/smail). Many sample
configuration files are available from Linux distribution CD-ROMs and FTP sites that show
different configurations. Obtaining one of these sample files, and then modifying it for
your host-specific details, is easier than building the files from scratch. The number of
options and details change with the release of smail, so check to see whether you have a
complete version.
The router component of smail handles the resolution of destination addresses, routing
to the next mail host for further forwarding, and determination of which transport should
be used to send the message on. The router component performs a number of tasks, first
determining if the message is for a local or remote machine (using the variable values
defined in /usr/lib/smail/config). If the message is for a local machine, the message is
handed off to the director.
If the message is for a remote machine, the message's address is given to router
drivers to determine which host the message should be forwarded to. The router drivers are
specified in the file routers (usually /usr/lib/smail/routers). The file contains the
names of the router drivers, each of which (in the order presented in the routers file) is
given the message destination address to see if they have information about the specific
route required to send the message.
You don't need to specify any other routers than the default configuration in most
cases. The default setup uses the following router steps, in order:
These default routings work for most systems, although you should comment out the UUCP
router if your system is not properly configured to handle UUCP. Otherwise, you will get
tons of error messages. If you do not plan to use UUCP for mail, you should also comment
out this router line to simplify the entire smail system.
A couple of other common situations need to be dealt with. If you are connected to the
Internet, there is a problem in that smail's router doesn't recognize the MX record
format. In order to properly support Internet mail, comment out the default router and
enable the BIND router instead. (If your version of Linux doesn't support BIND, you can
obtain and link a more recent version from FTP and BBS sites.)
If you are using both SLIP/PPP and UUCP connections, you may encounter problems with
smail waiting too long for a connection. To simplify this type of installation, rearrange
the order the routers are checked so that the paths file is checked before the resolver
router. In many cases, because UUCP is more efficient and faster than SMTP over a SLIP/PPP
line, you can disable the resolver-based router entirely.
When a router identifies the best route to the destination machine, it also gives the
transport required to communicate with that machine's mail router. The actual path to the
destination may be modified at this point. For example, if the remote machine
chatton@bigcat.com can best be reached through a UUCP link instead of SMTP, the
destination address may be modified by the router to bigcat!chatton (UUCP-style
addressing). Alternatively, a destination address may become more specific. For example,
the address chatton@bigcat.com may be resolved to a specific machine such as
chatton@whiskers.bigcat.com, if that address will get the message delivered more
efficiently.
Some UUCP routers use the /usr/lib/smail/paths file is used by to determine a path
alias. The paths file is ASCII only and contains a sorted list of entries with two columns
separated by a tab: the destination site name and its UUCP bang path. No
comments are allowed in the file.
This chapter has looked at the configuration of the smail mail system for UUCP and TCP-based mail connections. In either case, the configuration process is usually a matter of modifying a single file, unless you have several different connections to the outside world. It is the simplicity of configuration that makes smail popular with Linux users.
